结构化的思考、做事、成长
在每年自评、汇报、工作中总会感受到一些结构化带来的问题：
老板问我当前做的事情怎么样了，我讲了合作中的难点、视觉风格问题、业务情况、代码质量。。。工作的进展，说了半小时，老板还是get不到我做的事情的情况和价值。是老板不在意这件事、还是我语言表达能力不行？
我这一年做了很多事情，都有一定产出，但是跳出细节来看，发现对业务、对团队价值都不大。是我做得不好、还是运气不好做的事情不好？
最近流行codeless，我打算研究下可视化搭建；团队业务涉及到流程编排，我打算研究下TMF。。。一年下来折腾了不少成果出来，似乎老板也没有很认可。是我不讨老板喜欢还是做的事情没价值？
这些问题，根据我自己工作经验的总结，认为大都是对结构化认知不足和践行不佳导致的。
第一个问题：对事情的认知和表述结构化方面存在问题 - 结构化的思维相关问题
第二个问题：做事儿多而杂不成体系 - 结构化的工作模式问题
第三个问题：学习和成长缺乏重点 - 结构化的能力建设的问题
建立结构化的思维，以结构化的模式驱动工作，以结构化的体系构建自身的能力，小到写PPT、大到为业务提供更大价值，都是非常值得我们使用的模式。
阿里巴巴数字供应链事业部高级前端技术专家，承风，为大家分享他在建立和践行结构化思维过程中的方法论。
Structured：建立中心（问题、目标）。以中心的核心要素对中心进行分解，形成分类子结构。以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；对关键分类子结构进行分析，寻找对策，制订行动计划。
同理，逆向的顺序，对多种杂乱的内容，进行分类、剪枝、归纳汇总成一个中心。我认为也是结构化。
有很多相关的书籍：
领导者之剑:成功人士的5大突破思维技巧、金字塔原理、极简思考:来自世界顶尖咨询公司的高效工作法。。。
也可以参看很多结构化的应用方式：结构化面试、结构化金融产品设计、结构化系统开发方法。。。从多行业多领域的使用可以反思和加深自己的认知。
结构化的理论是简单清晰的（道的层面总是比较简洁），但实际应用中如何进行结构化、最有效的使用结构化却有很多经验（术的层面总是多变的）。在此结合我个人的经验给出一些建议：
建立中心
当我们接手一个业务需求、面对一项挑战的时候，应当先思考这个需求的核心目标是干嘛的。
结构化的建立中心
思考的过程也是结构化的，我通常会分解为两个子结构进行
这个业务需求当前的目标是什么。（事的维度）
目标是快速完成上线试一试业务效果：目标事的维度为高效稳定上线。
目标是建立后续业务铺开的基础方案：目标事的维度是强架构设计下的核心与功能拆分方案。
为什么需要我来做。（人的维度）
是因为我工作量还有buffer所有承担这部分：目标人的维度是完成职能范畴内的工作。
是因为我在这方面技术比较擅长：目标人的维度是利用事情强化自身能力和使用能力把事儿做好。
沿中心上行
对单个业务需求而言，从事、人两个维度建立起的中心即其核心，是最主要部分，建立一颗结构树的基础。但我们不应当停止于此，还应当向上推导：这个需求在整个业务的范畴内，是在哪一层次，哪一分类的。即应当更高层面、或整体业务和行业发展，对这方面业务是怎样的期许。（价值的维度）
一个团队接手某项业务或需求，其背后都会有思考。我们是期望借着这个业务打造一个平台，提升整体行业的表现；还是突击这个业务方向，占领局部的商业蓝海。。。
接到一个需求时一定要思考更大层面这事的价值，才能更好的判断优先级、做事模式。
例如：我们做采购系统，当前需求是，提供采购单列表，按总价范畴搜索单据的能力。按结构化的中心建立，它是：高效稳定上线（事）、我职能范围内的工作（人）。
如果止步于单个需求建立的中心，我们后续的分解应当是如何快速搞定、如何更稳定。。。
如果我们继续向上构建树，我们可以和产品、使用者深度沟通下为什么要做价格搜索
管理员期望能看到高价订单的情况。那么这个需求的上一个中心节点应当是：管理提效。
继续向上，是基于什么原因需要做管理提效？因为防止贪腐、提高工作效率。那么上一个中心节点应当是：降低成本。
依次向上，直到抵达整个业务的目标。比如总结觉得，我们的业务是构建一个集成高效的集团采购系统。
再以此反思：
降低成本是不是当前工作的重点？团队是否有足够的架构设计和人员组织来支撑？
下一步到到管理提效层面，订单的搜索是否真的是当前最佳的提效工具，因为用户如何定义高价格？他执行这种搜索式查阅工作是否真的是有效不遗漏的？查阅到了订单有问题他能做什么？。。。我们会发现这个需求背后更多的问题。我们也可以沿着更大的中心树，去思考是否构建更好的方案可以更根本的解决这个问题。
再回过头来看当前的任务，是否真的是高效稳定上线（事）、我职能范围内的工作（人）。或者当前最紧急的部分（用户直接需求嘛）是高效稳定上线（事）、我职能范围内的工作（人），但后续更要做更多的其他的根本性解决方案。
沿当前的中心向上建立更大的结构化的认知体系
会让我们对当前事情的判断（中心）更加清晰，也有更好的认知基础，极有利于与合作方的沟通碰撞和内容创新。
建立更大结构化认知体系的过程，也是深入业务、扩展认知力的过程。一定要多和老板、业务方交流，从各自认知的差异性上提升自身的认知能力。
此外，构建更大认知体系，对个人和团队发展也是有价值的
很多时候我们忙于业务实现，都没有花时间去思考业务的价值。一部分是因为忙，一部分是因为懒，一部分是因为不懂，一部分是因为我们是来做事拿工资的，而不是带着愿景想把事做好的。这都不是真正能把事情做好的方式。
作为团队的一员，我们不应当只做“花时间、生鸡蛋”的极低人效、技术外包的母鸡模式，而应当积极的尝试做“建机器、铺厂房、出产品”的工厂模式。这对业务和个人的发展才是积极的作用。
中心的分解
建立完成中心后，有多种对中心进行分解的方式。其目标在于将中心拆解为多个内聚的子部分。整体思想是MECE（Mutually Exclusive Collectively Exhaustive）原则，即相互独立，完全穷尽不重叠、不遗漏的分类。够借此有效把握问题的核心，并成为有效解决问题的方法。
一些分解方案的简介
SWOT
SWOT分析方法又称态势分析法：即Strengths 优势 / Weaknesses 劣势 / Opportunities 机会 / Threats威胁四类。最早用于进行企业竞争态势分析，对个人而言用于分析自身的竞争态势也是极佳的。
（如图，对团队数据可视化能力建设的SWOT分析示例）
SWOT分析法四个象限可以分别分类四大独立的方面，而其中SW部分 - 优势劣势一般用于分析内部条件；OT部分 - 机会威胁一般用于分析外部情况。又形成了两个独立而全覆盖的大类分隔。非常有助于看清楚当前的情况。
此外，SWOT形成的象限又可以结合跨大类进行组合分析
SO的关联部分，是我们做事的重点，重要紧急的。比如Node+可视化能力 =》我们可以构建基础平台。
WO相关的部分，是我们必须解决的，很多情况下是我们需要进行专享突破式学习的内容。比如图形学 + 基础框架 =》如果我们要做基础框架这个机会，那么必须补全图形学相关知识。
WT部分是威胁到这件事或者成长的部分，必须重视、避免、纠正。比如图形学 + 多公司发力基础框架 =》如果我们没有基础框架基础沉淀，又缺乏图形学相关学习目标或者相关引导，那么我们就应当放弃做基础框架。
ST部分是我们直面竞争的部分，如何发挥自身优势去面对威胁，需要有相关的抓手。比如Node + 成体系的ISV =》ISV肯定会在系统化建设上发力，我们必须使用node的基础能力提供更加灵活高效的解决方案。
AHP
AHP分析方法又称层次分析法：Analytic Hierarchy Process，将与决策总是有关的元素分解成目标、准则、方案等层次，在此基础之上进行定性和定量分析的决策方法。它是一种定性&定量结合，系统化&层次化的分析方法。
第一层是目标，第二层是分解的准则，第三层是实施方案。构建A1...A5与目标相关权重，形成构造判断(成对比较)矩阵。对矩阵进行层次单排序及其一致性检验，再计算B1....B3层总排序权值和一致性检验，按照权重结果进行方案优先级的判断。更多详细计算内容可参考MBALib。
我们在实际使用中有两种方式：
以层次建模的模式，对核心目标进行有效分解。即如果某一类分解，无法被赋予权重，则不是一个有效的分解。
根据层次分析建模，对当前事情优先级进行决策。在实际应用中我们即便不去精确计算权重，至少按此结构看各个工作目标与分解的相关性，亦是一种指导。
进行分解的顺序逻辑
中心的分解应当使用流程化思维。指的是找出事情发生的内在逻辑，思考的时候可以逻辑顺序作为参考。
时间顺序：中心执行的步骤、流程等。
结构顺序：中心的空间、地理位置、内部外部条件等。
程度顺序：中心的轻重缓急、重要性等。
。。。
以XMind为例
（规划的时间顺序分解）
（按相关性进行结构顺序分解）
（按照重要性即与鱼头的距离进行程度结构分解）
按照哪种顺序进行分解因个人爱好和事情的不同而不一致，没有优劣之分只有合适不合适。多加应用多做尝试不同模式，会不断提升自身思维和行为的逻辑性以更加结构化。
清理
事业是无限的，人力总是有穷、认知高度总是不够的。我们不能把分析出的所有点都做好，也不是分解出的所有层次都真正有价值的。那么针对分解的产出物，应当以数据挖掘的物料准备类似的逻辑进行前期处理，来提高效率、去除噪声。常用的分别为：
泛化：过度细碎的层次应当抽象总结到更高层次，以进行更有效分类。
补漏：针对中心，某些关键决策子层级缺失，应当补充完全。
剪枝：针对中心，与中心紧密度关联较低或无可操作性的部分应当去除，以降低整体分析复杂度。
泛化
例如我们要提高部门的研发效率，日常工作收集了一些反馈：开发环境不稳定天天抢日常部署，jar包冲突屡禁不止，经常有人push origin -f，前后端联调确定字段巨麻烦，对当前业务webx用起来不够顺手迅速。。。
这些问题都可以归纳到“研发效率提升要解决的点”这个分支下，但细碎的陈列让对问题的解决显得没有重点，后续遇到其他问题也没办法进行有效的区分。
泛化一般是这样的模式：我们有一些用户年龄，分布为10、14、35、42、55、72岁。可以抽象成年龄分层 - 青少年（10、14）、中年（35、42）、老年（55、72）。降低数据量提高内聚性。
针对上面的研发效率问题，我们可以按照研发工作的主要方面，泛化相关的问题：对当前业务webx用起来不够顺手迅速（研发架构）；抢日常部署、前后端联调（研发环境）、jar包冲突、强制提交（研发态度）。
在结构化中，不是越深、越细的结构是越好的，很多时候越内聚抽象的结构反而更有利于进行后续实操改进工作的开展。
补漏
例如我们要提升前端研发效能。通过调研、学习和思考，认为需要进行几方面的结构化建设：
高效的研发环境
极佳的研发工具
稳定的研发环境**（缺失）**
可测试和追述的代码表现
...
平台技术驱动研发
核心能力不断沉淀
非核心能力能无侵入的快速定制**（缺失）**
...
合理的团队人员结构
...
进行结构化的梳理可以更清晰的看出针对目标，哪些部分是我们缺失的。因而针对缺失部分的重要性和紧迫程度，可以更合理的安排工作，而非一味的在较强的部分进行优化、或者各种事情东打一枪西放一炮。
同理，对个人技术成长而言，整理针对当前行业发展下当前技术环境下个人能力的要求点，进行结构化分层和缺失标注，也是指明自身学习方向的好手段。
剪枝
在我们进行中心的层层分解时，我们即便做到了归类，也总会生产一些特别发散的点。针对这些点，我们应当进行非关键分类结构的减少，即剪枝过程。
通常需要进行剪枝的部分
是和其余结构关联不大的部分
针对当前核心问题是非主要相关的部分
兼顾该部分的成本比产出的效果更大
例如我们要通过只狼，一个牛逼的手柄花费的代价，和其对核心目标的提升是不对等的。如果要兼顾该子结构，可能对自己身体和心理造成更大的负影响，放弃是明智的选择。
我们在安排自身的学习成长也是类似的，是否需要报个昂贵的视频课程，是否需要深入研究TMF源代码，都应当看对当前自身的学习目标的结合度、性价比来做决策，是去是留。
结构化中，要果断剪枝，保持专注、保持可行性。
结构化是一个非常简洁的理论
建立中心；
以中心的核心要素对中心进行分解，形成分类子结构；
以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；
对关键分类子结构进行分析，寻找对策，制订行动计划。我们在思考、做事、成长时应当随时使用，对于梳理复杂问题、进行决策支撑都有很大好处。
最后回答下最开始的问题：
老板问我当前做的事情怎么样了，我讲了合作中的难点、视觉风格问题、业务情况、代码质量。。。工作的进展，说了半小时，老板还是get不到我做的事情的情况和价值：按照事情核心目标的达成情况，各子部分重点问题和解进行结构化的讲述，两分钟说清楚。
我这一年做了很多事情，都有一定产出，但是跳出细节来看，发现对业务、对团队价值都不大：先建立团队当前业务的核心目标，分解目标达成所需的各个部分，自身努力在某个部分上做深，或者补全当前缺少的部分，或者强力推进将团队目标向上拔高一层更大的目标。
最近流行codeless，我打算研究下可视化搭建；团队业务涉及到流程编排，我打算研究下TMF。。。一年下来折腾了不少成果出来，老板却不提名我晋升：先确定自身技术能力提升的目标，分解到需要提升的各个部分，针对不同部分向老板强求从事相关工作、在当前工作内尝试和深耕，从深入一个部分到横切一个面的能力提升，晋升自然水到渠成。